Subject: CLARIFICATION!: Names in ACTPU/LU

From: David Bryant/HQ/3Com <[email-masked]>
Date: 2 Jan 96 10:17:14 EDT

Just a quick clarification to everyone concerning my "NMVT-based" proposal 
regarding names in ACTPU/LU. 

I do not propose that NMVTs be used for LU names.  I propose that a bit in 
RSP(ACTPU) be used as a means to signal to VTAM that the PU in question 
supports receipt of CV0E for both ACTPU and ACTLU.  Because ACTPU will have 
already been sent at that point, it is necessary to send the ACTPU name via 
some other vehicle.  Thus, I suggested a specific NMVT for the purpose. (I 
disagree with the suggestion to send a second ACTPU as this is likely to cause 
quite a bit of confusion.)  Since RSP(ACTPU) flows before ACTLU messages, the 
intent would be for subsequent ACTLUs to carry a CV0E with the LU name.

Example Flows:

      PU                                                     Host 
         <------------     ACTPU   ---------------                     
          -------------    RSP(ACTPU) ----->
         <------------    NMVT(cv0E) ------->
         <------------    ACTLU(cv0E) -------
          -------------    RSP(ACTLU) ----->  
        <------------    ACTLU(cv0E) -------
          -------------    RSP(ACTLU) -----> 
                                     .            
                                     .

Dave Bryant
3Com Corp

---

From: "jim (j.) cobban" <[email-masked]>
Date: Wed, 3 Jan 1996 10:29:00 -0500

I think that Dave Bryant's suggestion for carrying the PU name in an NMVT
requested by an extension of the ACTPU reponse is clever.  However it does
strike me that it is more work in the PU 2 or gateway to implement support
for this NMVT than it would be to generate or map an XID 0 to an XID 3
response.

To support the NMVT solution the PU 2/Gateway is modified as follows:

  - add a flag (probably in the X'07' FMD-Usage CV) to the ACTPU response
    to solicit the NMVT.  If this is a gateway, then this means modifying
    the ACTPU response from the real PU 2, and possibly adding the CV.
  - add support for receiving a new MS major vector on an NMVT. 

The XID 3 solution requires the following:

  - add support for generating a format 3 XID or for mapping an XID 0 to an
    XID 3.  The contents of the XID 3 are a constant string, with the
    exception of the identification field which is either derived from the
    XID 0 or from provisioning.  This work does not need to be done if the
    PU 2/Gateway already supports format 3 XID, which it will if it already
    supports DDDLU, or if it supports T2.1.  If the PU 2/Gateway does not
    already support these functions, then support for this name on ACTPU can
    be bundled with adding support for DDDLU or T2.1.
  - add support for receiving name on ACTPU.

Both proposed solutions require adding support for receiving names on
ACTLU, as does support for DDDLU.

The NMVT solution is entirely self-contained.  It has no synergy with other
capabilities, in particular support of DDDLU and evolution to T2.1.  It is
my opinion that support of the XID 3 based solution is essential in most
implementations, so support of the NMVT solution would in almost all cases be
additional effort.  Even if an implementation saw no value in implementing
XID 3, it still seems to me that in most cases the NMVT solution would
require more code than the XID 3 solution.  Certainly in our Nortel PU 2
gateway product we already understand, modify, and generate format 3 XIDs,
however our current product does not examine the contents of any MS major
vectors within the NMVTs it passes through between the PU 2 and the host.

Although it is not an issue for those of us who only manufacture T2, T2.1 or
gateway boxes, it seems to me that the amount of effort required in
VTAM/NCP to support the XID 3 solution is substantially less than for the
NMVT solution because it is a small extension of the existing DDDLU
support.

I feel that it was unfortunate that when DDDLU was originally specified,
that the network name vector was not included in the ACTPU at that time.  If
it had been, we probably would not have this as an issue.

By the way, nobody has responded to the question I raised a while back on
why T2 support of XID 3 was explicitly removed from the formats manual at
the same time that DDDLU was added.

Jim Cobban   |  [email-masked]                        |  Phone: (613) 763-8013
BNR Ltd.     |  bnrgate.bnr.ca!bcarsf1f!jcobban       |  FAX:   (613) 763-5199
|                                                                             |
|   The opinions expressed are those of the author and do not necessarily     |
|   represent the opinions of Bell-Northern Research or Nortel.               |